Slice blocked BitPacked without decoding - #10250

Tracking Issue: #10167

Summary

Slicing a BitPacked array whose blocks have their own bit widths now runs as a kernel instead of decoding the whole array first. The result stays blocked and holds only the blocks the slice overlaps. Block offsets are relative to the first one, so the kernel reads three boundaries and slices the offsets child and the packed buffer without copying.

Changes

• SliceKernel slices blocked arrays; SliceReduce still declines them, since it can't read buffers.
• Release builds don't validate block offsets on construction, so the kernel rejects boundaries outside the packed buffer or off a 128-byte row.
• Host-resident Primitive offsets are read directly; other encodings go through execute_scalar.

Benchmarks

Local divan benchmark, not committed: slice 1500.. into 128Ki u32 values with block widths cycling 1 to 16 bits, then canonicalize. Apple M5 Max, median.

The kernel call alone takes 131 ns, against 58 ns for a single width.

Testing

• compute/slice.rs: ranges within, across and aligned to blocks, to the end, and empty, with primitive and FoR-encoded offsets; kept blocks; nulls and patches; slicing twice; invalid boundaries rejected.

Follow-up: blocked kernels for filter, take, compare/between, is_constant and cast.